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(54) SoflMune fental system aitd melhod for renting soflwafs 

(57) A software rental syolem is provided compris- 
ing sA least one rented progrBm permitting at least one 
service to a customer witfi a customer's reponee 
means, wtterein 



said rented program has no access to a customer's 
private key^ material. 

using asymmetric ayptography. said customer's 

reponse means proves to the rented program, that 

said customer's reponse mem has access to the 

customer's private keying nutferial. arxl 

said rented programi does not permit said at least 

one service to sakl customer unless the proof is 

successful. 
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(0001] With few exceptions, most computer programs are instantiations of intellectual property and execute upon 
demand after installation. Normally, one can build and install an inexpensive copy of a computer program by little more 

5 than simply executing a copy command. A physical asset such as an automobile, on the other hand, cannot be easily 
copied. As a result, it is much easier to provide rental of physical assets than rental of computer programs. In the case 
of a physical asset, the renter first pays a rental fee. and then physically takes possession of the asset. At the conclusion 
of the rental period, the renter returns the physical asset to the owner. In the case of software, on the other hand, it 
makes little sense for the customer to return the program to the owner because one cannot guarantee that the customer 

10 refrained from sequestering his or her own backup copy In the absence of adequate security measures, a customer 
acting in the role of an attacker, could potentially rent the software for a short period of time and subsequently use the 
sequestered backup without paying further rental fees. 

[0002] In this invention we define software rental as a computer system and method that securely stores rental 
(usage) records. For example, consider the time-of-use rental metric. If the customer, executes the rented software for 

15 one hour on the first day and two hours on the second, then the secured audit trails show one hour at the end of the first 
day and three hours at the end of the second day. Secure software rental implies that a customer cannot defeat system 
security by purging, replacing, or modifying audit trails. Normally, the software continually monitors the audit trails to 
determine when a threshold is exceeded. So. if the exanrple software has a five hour threshoW. then the customer may 
execute the software for two more hours and then the software stops. Another example threshold is the total amount of 

20 times that the software may execute. 

[0003] Some rental mechanisms that have all the properties listed above of our invention currently exist, e.g., Dongles 
[1]. Dongles have non-volatile memory which may be protected by passwords. This password protected memory may 
potentially used for software rental. A characteristic of this rental mechanism is that it requires the assistance of a 
secured rental device, e.g.. a Dongte. The secured rental device contains Secured Updateable Storage Locations 

25 (SUSU) that record information related to usage of the rented software. Each SUSL has the property that the SUSL 
resides on a secured devfce and provides protection against attack. Normally, at least one SUSL for each unit of rented 
software is required. For example, if a customer rents a word processor, a spread sheet, and a game, then the rental 
device(s) must provkle at least three SUSLs. These SUSLs are relatively expensive and difficult to administer, when 
compared with other storage on the customer's machine. e.g.. memory or disk space. 

30 [0004] Software rental, furthermore, significantly differs from a subscription to a network sen/ice. For example, sup- 
pose a software vendor provides a server to which customers connect via their software clients During the period of 
the connection, the server audits usage records, e.g.. connect tima The vendor assesses chaiges based upon the 
information recorded in the server's audit trail. This client-server example differs from tNs present invention because we 
do not necessarily require an on-line presence by the software vendor. Rather, after obtaining permission to use the 

35 rented software, the customer executes the software without any required network connectk)ns. Furthermore, the sub- 
scription service does not prevent the customer from caching frequently used items. 

[0005] An overview on asymmetric ayptoc^aphy. ftw exagr^\e on the RSA scheme, and probabilistic encryption, for 
example the Blum-GoWwasser probabilistic public-key enayption scheme can be found in [2). 
[0006] An overview over different probabilistic proof schemes, for example zero knowledge proof schemes {eg. 
40 Feige-Fiat-Shamir scheme. Guiltou-Quisquater scheme. Blum-FekJmann-Micali scheme. Brassard scheme. Crepau 
scheme, etc.) or witness hiding proof schemes (eg. Feige-Shamir scheme, etc.) can be found in [2]. 
[0007] An overview of digital signature schemes (eg. Rivest-Shamir-Adleman, etc..) and a Ibrmal mathematk»l def- 
inition of digital signatures can be found in [2]. 

[0008] An example of a message digest function (othen^vise known as a one-way hash function) is MD5 [3]. It is com- 

45 putationally infeasible or very difficult to compute the inverse of a message digest 

[0009] In [4J. ayptographk: randomness from air turlDulence in disk drives is desaibed. 
[0010] The Chi-Square Test, the Kolmogorov-Smirnov Test, and the Serial Con^elation Test are described in (5}. 
[0011] An asymmetric cryptographic mechanism includes pii)lic keying material and coresponding private keying 
material. It Is computationally infeasible to compute the private keying material when given no more inibrmatk)n than 

so the corresponding public keying material. In tNs invention, we use asymmetric ayptography in interactions between two 
parties. A and B. A proves to B that A has access to private keying material and B validates the proof. A does not dis- 
close the private keying material to B. 

Digital signature scheme 

55 

[001 2] A digital signature is an electronic analog of a handwritten signature. A digital signature proof involves at least 
two parties. A and B. After posting his or her puWk: keying material to a public location. A encrypts a message using the 
private keying material. Since anyone may access the public keying material, there is no message seaecy. However. 
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since A is the only customer with access to the private keying material, no one else can forge A's signature" by per- 
forming the encryption. Anyone may validate A's signature using the public keying material • simply decrypt using A's 
public keying material. 

[0013] An asymmetric confidentiality proof involves at least two parties. A and B. A possesses private keying material 
and B has no access to A's private keying material unless 6 discloses the private keying material itself (which B shoufcl 
not do). At the beginning. A and B have no shared seaet. During the method, a shared secret becomes known to A and 
B. 

[0014] In all asymmetric cryptographic schemes, each customer may post his or her public keying material to a put>- 
licly accessed directory without compromising the correspondirtg private keying material. The customer usually shouU 
guard his or her private keying material as a close secret: othenw^, the cryptographic system may not guarantee cor- 
rectness (secrecy). The best known mechanism for protecting one's private keying material is through the use of a 
smart card. In this case, tfte smart card is a device wi^ no interface for releasing private keying matermi ftn a non-ayp- 
tographtcally protected form). All cryptographic operatk^ns that directly reference the private keying material are per* 
formed on tfte snr^art card itself. As a result, no one can discover the contOTts of the private keying material stored on a 
smart card. 

[0015) Although smart cards provide the best protection, social factors of electronic conrmierce may provkie a role in 
ensuring priv^e keying mater^ protection. One of the significant difficUties associated with asymmetric encryptkKi 
services is aidhenticalkm. For example, if A posts his or her pubfic keying material to a ptdillc drectory, then how does 
B assess vaHdity? That is, a pirate may attempt to masquerade k A but post the pirate's keying material. Some com- 
mercial organizatkms provkie solutkms to this prot>lem by actsrig as Certification AutfuKities (CA). For (pos^y) a fee. 
the CA solkiits dentifying material from potential customers such as a driver's Kcense or passport After valicteting the 
identifying material, the OA posts the customer's public k^ing material to a public dffectory. and the CA signs a certify 
icate (using a dfgrtal signature with the C A's private key) tfwt hokte tfte customer's pubUc keying material. Slandaidizedr 
servk^s. for example X.500. may be adopted to help facilitate the use of directories that contain pubHc keying materiair 
[0018] Once a cudonw posts his or her pubtic keying material to the CA, the customer wi^ 
oK.^ ^ p^^Ttrrt ^rrrhw frrfYntft Irnyinq mntfiriTil Fnr ^nmn mrymmnlrir Imyn, if the n rtnmpr*i privtrto Iroying matq< 
rial were to become untaiowing^ compromised, then the customer woukJ have cause for significant concern. FdOk 
example, in the case of RSA keys that can also be used for digital signatures, networiod vendors could potenliali^ 
authorize electronic commerce transactions. -C 
[0017] The object of the presemtnventk)n is to aeate a ayptographk:atty secure software ren^ ^ 

Summary of the Invention ^ 

[0018] According to the inventkxi there is provcled a software rental system comprising at least one rented programi^ 
permitting at least one service to a customer with a customer's resporvse means, wherein W 

- sad rented program has no access to a customer's private keying material. % 
using asymmetric cryptography, sakf customer's response means proves to the rented program, that sakJ cus^ 
tomer's response means has access to the customer's private keying material, and 

• sakJ rented program does not permit saxd at least one service to said customer unless the proof is successful. 

[001 9] According to a further aspect of the inventk)n there is provided a software rental system compri sin g at least 
one rented program and private keying material such tfiat the software rental system securely stores audit traile. 
wherein the correctness of saki audit trails is validated using asymmetrk: cryptography. 

[0020] According to a further aspect of the invention there is provkled a method of distributing a program to a pluraitty 
of customers wherein each customer has a software rental system as described above, and wfierein every customer 
receives an kientk:al copy of said program. 

[0021] According to a further aspect of the inventx)n there is provided a method fbr renting software comprising at 
least one rented program pernrtHting at least one servk:e to a customer with a customer's reponse means, wherein 

• said rented program has no access to a customer's private keying nr>aterial, 

• using asymmetric cryptography, said custon^r's reponse means proves to the rented program, that said cus- 
tomer's reponse means has access to the customer's private keying material, and 

- saki rented program does not permit sakJ at least one service to saki customer unless the proof is successful. 

[0022] According to a further aspect of the invention there is provkled a method fbr renting software comprising at 
least one rented pro-am and private keying material such that the software rental system securely stores audit trails, 
wherein the correctness of sakI audit trails is vacated using asynrvnetric cryptography. 
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[0023] We provide a new mechanism in which the number of required SUSLs is not a function of the number of rented 
programs. In particular, this invention requires only a single SUSL regardless of the number of rented programs or 
whether or not these programs simultaneously execute. For example, a customer could potentially simultaneously exe- 
cute 100 or more rented programs while using only a single SUSL The SUSL requires no nrwre than 128-bits in order 

5 to protect an unlimited number of rented programs. In some cases a single 32-bit SUSL or a single 64-bit SUSL may 
be sufficient. As we will describe later, we use the SUSL to denote a single non-negative integer. We use this integer 
as a counter that begins at an initial value (normally zero) and ends at the highest value that can be represented by the 
counter. Under normal circumstances, it is not possible to count through all of the possible numbers that can be repre- 
sented by a 128-bit counter. Even if one were to build a machine that could increment the counter trillions of times each 

10 second (one would not normally want to count this fast), then it would take millions of years to reach the maximum value 
of the counter (2^28.^) 

[0024] This invention also provides a new method for distritjuting rented software. In this method, a customer may rent 
new applications, from any vendor whenever he or she wishes. The customer does not need to install new external 
rental devices or new SUSLs. 

IS [0025] The main motivation from the perspective of security for requiring at least one SUSL is to protect against the 
backup and restore attack as described below. Suppose that a rented application requires no SUSL. An attacker may 
break security by performing the following steps. First, the attacker in the role of an authorized rental customer, legiti- 
mately rents a program. Next, the attacker builds a full system backup of all of the non-volatile memory on the attacker's 
machine. Next, the attacker executes the rented program. Next, the attacker shuts down and reboots his or her 

20 machine. Finally, the attacker restores the state of the non-volatile memory to the original state at the time of the 
backup. At this point, the attacker has destroyed any possible record that the program was previously rented. An SUSL. 
on the other hand, counters this attack because an SUSL has the property that the information contained in the SUSL 
cannot be modified in an unauthorized manner. As a result, the attacker s restore operation cannot ovenwrite the SUSL 
with the purpose of defeating security. 

25 [0026] Since we cannot ensure that a customer deletes all copies of the software at the conclusion of the rental 
period, we provide an alternate approach. We lock the software so that the customer cannot execute the software with- 
out first providing an appropriate key. At the end of the rental period, we prohit)it the customer from subsequently using 
this key or any copy of the key. Therefore, at the conclusion of the rental period the customer can no tonger use the soft- 
ware because the customer will no longer be able to provide an appropriate key. 

30 [0027] In a further aspect of the invention there are multiple rented programs, wherein 

• said rented programs access the same public keying material, and 

- customer's private keying material is stored on a smart card. 

35 [0028] To further improve the security it may be advantageous that 

- at least one usage parameter of said at least one program is stored in an audit trail, and 

• said rented program does not permit said at least one servkse to said customer unless said at least one usage 
parameter is within a predetermined threshold. 

40 

[0029] In a further aspect of the invention sakf at least one usage parameter is a rental time period for renting said at 
least one program. 

[0030] In a further aspect of the invention sakJ at least one usage parameter is an amount of usage of said at least 
one program. 

45 [0031] To further Improve the security ft may be advantageous that 

sakJ at least one usage parameter is checked multiple times, and 

- sakl rented program does not permit said at least one service to said customer unless said at least one usage 
parameter is in a predetermined interval each time it is checked. 

so 

[0032] To further improve the security it may be advantageous that there is provided a rental server that synchronizes 
access to a smart card on whwh a customer's private keying material is stored and/or to an audit trail in which usage 
parameters of said at least one program is stored. Thus, there is a central instance which is responsible fbr much of the 
software rental (but not necessarily security). 
55 [0033] In a further aspect of the invention said program stores said at least one usage parameter in said audit trail, 
[0034] In a further aspect of the invention, aspects of said audit trail are stored securely. 

[0035] In a further aspect of the invention. portk>ns of sad audit trail are stored on an medium that is not secure. This 
makes the system easier and less expensive to be realized without sacrificing security. However, aspects of said audit 
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trait are stored in an SUSL (the SUSL stores a single counter value). 

[OOSt] To further improve the security it nnay be advantageous that the smart card peHbrms an atomic routine that 
txith executes a dgitaJ s^nature and an operation computed over an SUSL off said smart card, where the value held in 
the storage location change over time. 
5 [0037] To further improve the security it may be advantageous that the system includes a ksyftle for holding piMc 

keying material. 

(0G3B1 To further improve the security it may be advantageous that said pubfic keying ntaterial held in said keyfile is 
ayptographicalty secured, whereby it is computationally not feas^ to alter any portion of the keyfile. including the first 
putafie keying material, without altering the cha&enge means (defined later). 
io (0(^ To further improve the security it may be advantageous that keyfie includes information identifying said cus- 
tomer said program h^ been supplied. 

[004^ To further improve the security it may be advantageous tftat said keyfile includes decoy bits fbr disguising me 
said public keying material held mer«n. 

[0041] To further improve ftexibilfty. it may be possible to use software rental without defining a threshold. In this case. 
15 the software may be rented without limit Howevo'. the customer is trusted to periodicatiy send his or her audit trails to 
the vendor and submit associated paymem. 

^figf PwriBt»ftn of ttig Prgyfipgs 

20 [0042] 

Figure 1 is a bk)cfc diagram showing the architecture of the software rental system. 

Figure 2 is a bkxk digram showing the software conponents that are recced to be in^ed in the customer's 
25 machine. 

-s 

Rgure 3 is a flowchart showing the operation of a random number generator used to generate nonces. ir. 
Figure 4 is a block diagram showing a rental software purchase scenark). r 

30 

Rgure 5 is a block diagram showing the smart card architecture. 

c 

Figure 6 is a block diagram showing an example audit trail. ^ 
35 PescrtoliQn of an gmbotfrnwit rf the tnvgntion c 

[0043] One embodimem in accordance with the invention wifi now be descrtoed by w^ 

the accompmiytng drawmga m 
[0044] Figure 1 iOustates the system's 100 architecture. Potentially multiple applk:2dions (progranv) of software 

40 reskte on ^e system where each appH catw>n has its own keyfile. which is explained in detel Mm. Rgure l.aiuetrates 
three appHc^ions. a \Atord Processor 104. a Spread Sheet 1 05. and another applk:atk)n 106 which access l«yfles 1 01 . 
102. and 103. respeclk ^. m some cases multyte appBcitens 104, H)5. 108 may share a common ksyfttei 
[0045] Eachoftheapplk»tk)ns104. 105. 106 accesses its keyfHe 101. 1 02. and 103 to extract the customer^ piMc 
keying material as descrbed later in detail. 

45 [0046] Each applicatk)n vendor inserts rental instructions into a copy protected program. These rental instructkxis 
create k3g records, eg.. 109. 1 10. 1 1 1 . For example, every fifteen minutes that Word Processor 104 executes. Wbrd 
Processor 104 creates the folkswing log record: .Word Process WP with publk: key 
9828a8cl2a5873654bac6845l 7cl3afe3 executed for 1 5 minutes'* (note that the record coukf store the message digest 
of the public keying material rather than the pidslk: keying material itself). Next, the applk»tk)n sends its tog record to a 

50 Rental Sen/er 107. The Rental Server 107 inserts the log record at the end of a secure audit trafl 108 stored at a poten- 
tially unsecured storage location, e.g.. a file on a disk. The Rental Server 107 relies on the assistance of a Smart Card 
112 for security. 

[0047] An application, e g.. 104. 105. or 106. may choose to create a log record that contains any arbitrary string of 
bits with arbitrary length. In adcfitkMi. or in lieu of recording time, an application couM potentiaBy tog the number of times 
55 that the appNcatbn or some of its modules executes. For exanpte. SS 1 05 coukf potentially append a single tog record 
each time SS boots: plication SS with public key 768230aac8239d9df88cfe3c7b832a is executing". Different types 
of audit records, e.g.. time of usage or number of times that usage occurred may appear in the same audit trail. Multiple 
rented applications may sinrultaneously use the same audit trail. 
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[0048] One obtains software rental by matching thresholds against the audit trail. Figure 4 Illustrates a customer 402. 
who rents software from a vendor 401 . First, the customer 402 sends a request to rent the software to the vendor 401 
in an order request 403. In this example, the customer purchases six hours of application 104. After receiving payment, 
the vendor sends to the customer a keyf ite 404 that contains a usage authorization. In this case, the keyf ile 404 permits 
5 six hours of execution by application 104. The later desaibed keyf ile 404 may potentially contain other information, e.g.. 
copy protection or licensing information. 

[0049] Periodically, the rented application, e.g.. word processor (application) 104. examines the audit trail 108. If the 
audit trail 108 is not valid, then word processor 104 does not permit itself to be rented. However, if the audit trail 108 is 
valid, then the application 104 analyzes the audit trail and compares the analysis against the keyf ile 404. For example, 

w application 1 04 counts the number of log records that describe 1 5 minute intervals. Next application 1 04 looks into the 
keyf ile 404 to locate a rental threshokl whk:h in this present example is 6 hours (24 x 15 minute intervals). If application 
1 04 locates fewer than 24 of its log records denoting 1 5 minute intervals, then applicatton 104 continues executing. Oth- 
enwise. application 1 04 does not permit itself to be rented. In the latter case, the customer must purchase a new keyf ile 
in order to continue renting application 104. If application 104 were to exceed its rental threshokl. then other applica- 

15 tions. e.g.. spread sheet 105 and other application 106 would not be effected. That Is. each rented application views its 
own records from the audit trail without interpreting records created by other applications. 

[0050] From the discussion above, we can see that the architecture implements software rental provided that the 
rented applications, e.g.. 104. 105. 106. can unequivocally validate the audit trail 108. The following properties should 
be satisfied: 

20 

1 Holes: A rented application, e.g. word processor 104. in this present example validates that the audit trail con- 
tains all of the records that have ever been written regardless of application. If an appHcatkjn has previously written 
ten log records, then the rented application, e.g.. word processor 104. wouki not validate the audit trail if the rented 
application couM not locate all ten log records. We require an absence of holes, because we do not wish to permit 
25 an attacker to delete Individual log records in order to destroy a record of usage. 

2. Modification: An application. e.g.. word processor 104. must unequivocally conclude that no unauthorized 
attacker modified any of WP's tog records. Othenvise, for example, the attacker could nrxxlify all of the 15 minute 
log records to 1 5 second log records in order to dramatk^lly increase the amount of time that the software may exe* 
cute. 

30 3 Current: A rented application, must be able to validate that the audit trail 1 08 is current. Otherwise, the audit trail 
108 could potentially be okl. thus hkiing relatively new audit recads 109. 1 10. 1 1 1 . One woukJ not wish, for exam- 
ple, an attacker to perform the backup and restore attack. 

[0051 ] These three properties remove all incentive for an attacker to con-upt delete, lose, or otheiwise abuse an audit 
35 trail 1 08. If the attacker were to render the audit trail 108 invalkJ. then ail of the rented applications 104, 105, 106 would 
Identify the abuse and subsequently refuse rental. 

[0052] In order to provide security, the architecture requires a smart card 112 that performs asymmetric cryptography. 
In this present example, the smart card 112 executes digital signatures. The smart card 1 12 contains private keying 
material 501 and a counter 502 (see Figure 5). 
40 [OC^] When the customer obtains the smart card 1 12. the smart card 112 is in a secure state. The smart card pro- 
vides exactly two sen^ices that access either the private keying material or the counter: SignAndlncrement() and Get- 
Counter Q. described in pseudo program code hereinafter (note that the symbol // denotes a comment and ^ denotes 
the assignment operator): 

45 



so 



55 



6 



EP0885148A1 



Signature SignAndlncremant (HASH h) // h is a message digest 
BEGIN 

[ll Compute the message digest of h and the smart card's 
counter, i.e., h' <- hash (h, counter) 

(2) Sign h' with the private keying material 

[3] Increment the smart card's counter by 1 

[4] return the digital signature computed in step [2] 

END 

integer GetCotinter ( ) 

BEGIN 

[Ij return the current value of the smart card's counter 

END 

[0054] Consider the following exanple trace. Suppose that the smart card's counter has an initial value of 6 and that 
one executes the following operations: v 

(i) Signaturel <- SignAndtncrenrient(hash(.mr)) -7 
(ti) Signature2 <- Si9iAndlncremerit(ha8h(.nfi2'^) 

(in)int1 < QetCounter() ^ 
[0055] The results of this example are: 

• Signaturel gels the dIgM signature (using the smart carcTs private Keying material) of hash(hash(^i ').6) & 

• Signature2 gets the digitelsignalure (using the smart card's private 

• inti gets 8 

IQQSS] Theaudtttmii lOScontairvafistof records, where each record has tour fiekls: nonce, string, counter.^ 
natura The data input into the signature is ha6h(hash(nonce.stnng).counter). Rgi^e 6 ilhistrates an example audit trail 
with four recofda In the first record, the nonce has the v^ue 96. the string is .WP 15 minutes public key 
9828a8cl2a5873664bftc6e45l7d3afe3'' (where 9828a8cl2a5873654bac684S17d3afe3 denotes the meeeage digest 
of a real public key), the counter's value is 0. and ttie digital signature is of haah(haeh(96.*WP 15 minute pubic key 
9828a8cl2a5873e54t)ac684517d3dfe3'^,0). Here, the digitiri signature was provided using the smart card's private 
keying material which corresponds to public keying material 9828a8c12a5873654bac68451 7d3afe3. This public keying 
material may be extracted from WP's kayf ile. 

imSTl The counter never rolls over from its highest value to zera When the counter reaches its highest value, ag.. 
2^^-l. the system stops. 

[0058] A rented applk:ation appends a record to the audit trait by executing the Write routine, where the Write routine 
is efTt)edded within the rented applications. This routine generates an audit record and then sends the audit record to 
the Rental Server 107. The Rental Server 107 writes the audit record into a non*volatae. stable image of the audit trail, 
e.g., on one or more files The Rental Server 107 synchronizes access to the smart card 112 and the aufit trail. The 
Rental Server 107 cannot execute in a manner that thwarts system security. i.e.. the rented applications do not trust the 
Rental Server 107. If the Rental Server 107 were to act incorrectly, then there couUpotentiany be a denial of s^^ 
because it may be the case that the remed appficatk)ns coukJ not valklate the audit trai^^ 
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[0059] The Write routine is provided below in pseudo program code: 

Boolean P^^ri te (String str) 
BEGIN 

[1] n ^ generate a new nonce 

[2] hi ir hash( n,str) 

[3] s ^ SignAndlncruient (hi) 

// below, c is a local copy of value in the smart card 
[4] c ^ GetCounterO 

// below, decrement by 1 has no affect on smart card 
[5] decrement c by 1 
[6] h2 <r hash(hl,c) 

[7] validate that s is the signature of h2 against the. 
public key found in the keyfile (if the validation 
fails, then return failure immediately without 
executing any further steps; the keyfile will be 
described later in detail) . 

[8] create the audit trail r <r <n,str,c,s> 
[9] append r to the audit trail 

[10] return TRUE if all of the preceding steps succeed, 
otherwise return failure 

END 



45 [00601 The ValidateTraii routine is also embedded in the rented application and should be executed periodically and 
is provided below in pseudo program code (assume that the system started with an initial counter vaKje of zero): 
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Boolean ValidateTrailO 
BEGIN 

tl] c 4- GetCounterO 

[2] Writeic) II use the Virite routine above, exit if 
// failure 

(3 J r <- Last record in the audit trail // this is the 

record that we just wrote in step [2] 
[4] Validate the signature stored in r against the 

public key stored in the keyfile 
[5] Validate that c is the same as the counter stored 

in r 

(6) FOR i<-0 UNTIL there are no more records, 

INCREMENT i by 1 
. th 

[6.1] r i record from the audit trail 

[6.2] Validate the signature stored in r against 
the public key stored in the keyfile 
// Signature validation comprises the message 
// digest recomputation 



[6.3] Validate that i is the same as the counter 
stored in r 

[71 END FOR LOOP 

[8] if all of the above steps succeed, then return TRUE, 
otherwise return FALSE 
END 



[0061] In steps [4] and [6.2]. all of the input for the validatton is from the audit record itself. By carefiiBy analyzing all 
of the steps in the iVr/^ and VaUdateTraH roi^nee. it is dear that any attadt that thwarts the attended use of these rou- 
tines causes failure. In this case, the rented applications notice the failure and do not pemnt ttiemselves to be rented. 
55 [0062] The mechanism for recovering from a failure deperxJs upon the vendor for each particular remed application. 
The vendor may. for example, issue a new keyfile upon some customers* requests. Perhaps, the most significant issue 
is recovery from acckf ental loss of the audit trail that may occur due to a disk error. In order to protect against this situ- 
ation, the Rental Server 107 should t>e responsit)le fbr writing all records to the aufit trail on behalf of all rented appN- 
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cations. The Rental Server should maintain a primary audit trail on the local fixed disk and at least one backup audit 
trail on a separate medium, e g., a floppy or a network file server One may. for example, provide a service that permits 
the Rental Server to e-mail audit trails to a secured network backup sen/ice. In this case, one can ensure privacy by 
permitting the rental server to encrypt the audit trail before transmission. 

5 

Software Components (see Rgure 2) 

[0063] We use the term challenge means to denote the portion of a rented program that implements components of 
this invention. The challenge means includes the implementation of the Write and ValidateTrail routines. In addition, the 
w challenge means instructs the remainder of the program concerning how to operate depending upon the results of the 
Write and ValidateTrail routines. In addition, the challenge means interacts with the program's keyfile as desaibed 
below. 

Keyfile 404 

15 

[0064] The creation of the keyfile 404 is performed by a keyfile generator, whfch is a program that executes at the 

vendor's facility The vendor 401 must take care to guard this program. 

[0065] In use of the keyfile generator, an operator enters the following information: 

20 Vendor name: Vendor name is the name of the vendor s company. 

Vendor password: Vendor password is the password that unlocks the vendor company's private keying material. 
Company employees who do not know the password cannot generate keyf Hes, 

25 Customer name: The customer name is the distinguished name of a customer (defined in [2]) for whom to generate 
a keyfile. The name indexes into a database of public keying material. 

Keyfile name: The keyfile name is the name of a new keyfile. 

30 [0066] After obtaining this information, the keyfile generator buiWs the keyfile 404, containing a customer information 
string (CIS) desaibed later. Portions of the keyfile 404 appear to the customer 402 as a completely random sequence 
of values. 

[0067] Buikling of the keyfile 404 involves the following operations. 

[0068] First, the keyfile generator creates a file and inserts the customer's puWk; keying material into the file, along 
35 with thousands of decoy bits. In the present example, each keyfile 404 contains approximately 480.000 decoy bits. This 
number of bits represents a significant amount of decoy material, yet can fit into a standard e-mail message. 
[0069] Each keyfile 404 stores the CIS in a different location. Additionally, each keyfile 404 has encrypted customer 
information embedded in it without disclosing the required encryption key. This encrypted customer information permils 
a vendor to easily identify the owner of a keyfile 404 in the event that the keyfile 404 appears in a puWk: tocation such 
40 as a bulletin board. The keyfile generator then encrypts and re-encrypts the keyfile (or portions of the keyfile) 705 nul- 
tiple times, using different algorithms. Finally, the keyfile generator signs the keyfile 404 usmg the vendor's private key- 
ing material by applying a digital signature algorithm. 

[0070] A keyfile is said to be validated if the challenge means of the rented application (described below) can validate 
the vendor's signature using the public keying material stored in the challenge means' binary and access the decrypted 
45 CIS stored in the keyfile 404. 

[0071 1 After having created the keyfile 404. the vendor's computer sends the keyfile 404 to the customer 402 by elec- 
tronic mail. 

[0072] The CIS is a string that contains the customer's public keying material, the customer's access rights, and pos- 
sibly a rental threshoW. The access rights provkJe information to selectively enable functwnality. Fa example, an 

$0 access right may potentially authorize the program to execute the print function. A different access right couW poten- 
tially permit the application to send audio information to the customer's speakers. Presumably, highly trusted custom- 
ers, or customers who pay more money obtain better access rights in their keyf iles. The keyfile 404 may have multiple 
uses. e.g.. authorization for the applicatk)n and rental information. In the following, the operation of the rental mecha- 
nism is described in nwe detail. This is performed when the customer initially attempts to execute the rented program. 

55 [0073] When the challenge mechanism 202 starts the process, the challenge mechanism 202 (see R^Mre 7) 
accesses the keyfile 404 associated with the rented application and calls a signature validation functkjn 203 in the chal- 
lenge mechanism 202 to validate the vendor's signature of the keyf ile 404. using the vendor's public keying material 201 
that is embedded in the challenge mechanism 202. This validation of the keyfile signature ensures that an attacker can- 
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rtot modify the keyfile 404 or rts digital signature without additionally modifying the challenge mechanism 202. The ven- 
dor 401 may opfona«yaugm«rt this protection using aricfitionalpro^^ 

modified, the cheOengt mechanism 202 hangs the rwted program, or othenmse dsturbs normal program SMecution. 
(00741 Assuming the si^wture of the keyfite 404 is validated, the challenge mechanism 202 then parses tfte keyfile 
404. usir«i a proprietary, vendor-specific algorithm, to locate the customer's public keying matenal in the keyfde 404. 
and extracts the custonter's putrik: keying material. 

(007^ SutDseqyently. whmem required by the software rental mechanism, the challenge mechanism (chaOenge 
means) executes tfte sof^Rwe rental protocd as de8crS)ed earlier. That is. th^ 
records to tfie audit traS as descrft>ed earlier. 

Nonce geneiBtor 

[OOWq Generation of a nonce is performed by a nonce generator included in the challenge mechanism 202. Operation 
of the nonce genentor is as (oftows (seef^e 3). 

10«?7J Fir«, the nonce generator emeries a large number of system parameters. e.g. the system time, me amount of 
space remaimng free in the page We. the number of logical disk drives, the names of the files in tt>e operating system s 
directory, etc. 

[0078] Next, the nonce generator builds a random numt>er. using a rarxtom number generator. The random nun^ 
generator consists of two process threads, referred to herein as Thread l and Thread 2. Figure 5 showe the operation 
of Thread 1 . which is the main thread of the random number generator. 

I007SJ (Box 301 )Trvead1fir^CTeates a data structorevahjejist for holding a list of court 
empty. 

[00M| (Box 302) Thread 1 sets a currert counter vdue to zero, and sets a done J«t flag to FALSE 
ffiOi] (Bc» 303) Tfo«ed1ttten forks Thread 2. Thread 2 poets an asynchronous 

the disk access is connpl^V\A)en the dM access is conriplate.^ test flag to TRUE. Mole tiiat 

Thread 1 and Thread 2 ^we the done.teet flag. 

{0082] (Box 304) Thread 1 inaements the courter value by one. 

[0083] (BoK 305) Thr^ 1 then te^ whether tt>e done Jest flag is now TRUE, indcating that tiie cfek access mitiatBdSr 

by Thread 2 is c(»TtpJeta If done.test flag is FALSE, the thread retorns to 

for the disk access to complete. Thread 1 continually incrments the counter value. 

[0084] (Box 306) When donejest flag is TRUE. Thread Iterminales Thread 2. an^ 

first free location in value.tist. 

[0086] (Box 307) Thread 1 then calls a Stol^est function, which estimates the degree of randonmss of the counts 
values (or portions of counter values, e.g.. tow-order bits) saved in vatoe.list. This function may use the Chi-Squvav 
Test. tt)e Kofrnogoiov-SmimQM Test or the Serial Corretatton Test whk:h are deserted in fq. The Stalstest fUnctiona 
may be optimized to ensure that conrtpik:^ cido^tions are not repecrt^ 

returns a value which indk^ates how many tow-order bits of each saved counter value shoufcj be consklered random. • 
[0086] (Box 308) Thread 1 conpares the value returned l>y the Statstest function when corftoined w^ 
the vahie Jst witii a predetermined threshokt vatoe. to determine whether enough random bits have now been gener- 
ated. If not enough random bito have been generated, the process returns to box 302 above, so as to ge^ 
anotfw counter vakia 

[0087] (BoK 30^ Mwi the reeiuired number of random bfla has been g enerate d. Thread 1 extaota the speciried 
nuiTtMr of tow^srder bita from each counter value in tiie vatoe.^^ 

dom numt)er. 

[0888] tn sionmary. it can be seen that the random number generator exptoits tiie unpredlctiribility in ttie timing of a 
series of disk accesses as a soiree of rmtomness in the generation of nonces (see [4]). By IdrMng new threads on 
each disk access, the random number generator also exploits unpredtolabilities n the operation of the operating sys- 
tem's scheduler as a second source of randomness. 

[0089] The analysis perfomied by the Statstest function permits the random number generator to self-tune tar any 
speed processa and disK by cornputing the number of low^yder bits of each saved coun^ 
pte. a system with a high-variance cfisk access time will generate nrme random b^ 

a tow-variance disk access time. For example, for a Quantum 1 080s disk (6ms average write time), and a 486 66 Mtiz 
processor, the system generates approximately 45 bits per second. Alternatively, one may hard code ttie number of bits 
per-disk access and use a de-skewing technique to ensure a good degree of randomness. 

[0090] The nonce generator also queries the operating system to ensure that it posts each disk access to an actual 
disk. The final output nonce is formed by combining ttie output random number from the random number generator witti 
the result of querying the system parameters as descrit>ed atxive using a message digest 
[0091 ] The nonce generator desaibed above worths best when executing on an operating system ttiat provkjes direct 
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access to the disk, e.g.. Windows 95 or Windows NT 4.0. In such an operating systenr), special operating system calls 
available to programs executing in customer space permit a program to bypass the operating system's internal buffering 
mechanism and write directly to the disk. Most progranis do not take advantage of these special operating system calls 
because they may be relatively inefficient and difficult to use. On Windows 95 and Windows NT. a program may only 
5 use these special calls if the program accesses data that is a multiple of the disk's sector size by querying the operating 
system. 

[0092] If the operating system does not provide direct access to the disk, then the challenge mechanism 24 could still 
use the disk timing random number generator. However, in this case, the quality of the generated values woukJ have a 
greater reliance upon unpredictabilities in the operating system's scheduler as opposed to the variance inherent to the 
w disk access time. 

[0093] The example of the invention desaibed above assumes that the operating system permits a program to fork 
multiple threads within a single address space. Additionally, the example of the invention assumes that the operating 
system permits the threads to access synchronization variables such as semaphores. Most modern operating systems 
provide these services. The example of the Invention uses multiple threads to implement a mechanism which quantifies 
IS each disk access time. However, if an implementation of the invention were to execute on a system that does not pro- 
vide multiple threads or synchronization variables, then the nonce generator could substitute other mechanisms, e g. 
querying a pfiysical dock. 

Sonf^e Possible Modifications 

20 

[0094] In order to improve performance, one may augment the system with a trusted audit trail validation service. 
Here, the trusted service periodically validates an audit trail and then appends a new audit record, the validator record, 
that securely vouches for tine previous records. Example information that the validator record may contain is a digital 
signature of the hash of all preceding audit records in the audit trail (the digital signature uses the private key of the audit 
25 validation service). Henceforth, rented applications need not validate digital signatures of records that precede ttie val- 
idator record. The audit trail validation service could be implemented by a third party that is accessft)le via a network or 
e-mail connection. 

[0095] In the ValidateTrail procedure's steps [5] and [6.3], it is possible that the counter value of the initial record is 
not zero. In this case, the counter value starts at offset and steps [5] and [6.3] must take offset into account in the com- 

30 parison. 

[0096] Note that the vendor of the rented application trusts the smart card to avokj releasing tiie private keying mate- 
rial, Additionally, tiie vendor of the rented applk^tion trusts that the smart card uses its private keying material in no 
functk)ns other than SIgnAndlncrement and QetCounter. The vendor of the rented applicatk>n may wish to vatidate the 
smart card manufacturer and/or personalizer. 
35 [0097] A vendor may aeate and distribute an applfcation after a customer obtains a smart card. In this case, the ven- 
dor simply creates a software rental keyf ile for the custonter and sends the keyf ile to the customer (possibly after receiv- 
ing payment). 

Universal Private Keying RAaterial 

[0098] In a variant to the example mechanism, all customers rent ttie software using the same public/0rivate key pair. 
Hiere. the vendor trusts that the smart card operates correctiy. and never releases the value of the private keying mate- 
rial outside of the smart card. As in the case of Figure 5, the smart card contains both private keying material 501 and 
a counter 502. Additionally, the smart card contains a unique serial number, where no two smart cards have the same 
45 serial number. Step (1 ] of the SignAndlncrenient routine in^emented on the smart card differs from the one described 
above as folkDws: 

[1] Confute the message digest of h and the serial number and the smart card's counter, i.e.. 
h' i- hash(h.$erial.number.counter) 

50 

[0099] In addition to tiie SIgnAndbicrament and the GetCounter routines, the smart card additk)nally provkles the 
GetSerialNumber routine: 
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string OetSerialNun^r ( ) 

BEGIN 

{1] return the smart card's serial number 

END 



[01001 The customer additionafly sends his or her smart card's serial number. The keyfile 404 contains the (bOowing 

infbrm&don: 

• The universal public keying material potentially shared by all customers 
The unique serial number of the customer's smart card 

The hash records stored in the log file, take into account tfie serial number. For exanple. the first hash record of Rgure 
6 has the fbnowing Inform^ion for a message signature: 

S^n^uie of ha8h(hs8h(96.WP...).8eriaLnumber,0) 
[01(h J The Write routine step (61 has the following mocfification: 
(6J h2 ^ ha6h(hl.serml_number,c) 

The V^a/idaterra// routine's steps Wand 16.21 must ^ 
We do not specify the vettide that the and V^/x/a/efra// routines use to otMain the serial nun^ 
card. One couW. for example, cpiery the snrwrt card a sintfetkne and then store the serial nunrt» 
fie system. ^ 

10103] A sofNare vendor carid potentially provide a rented application witti a conplex threshold odculation. For 
example, the vendor nuqf rent blocks of 1000 units, for each hour that the sofbMare executes between 20.00 (8:00 PM)» 
and 6,00 (6.<)0 AM) ttie next morning, the tog reojrd defines one unit; and ^ - 
the tog record defines two units. Sa for example, a customer couto potentially use the software for 1000 nighttime 
hours. 500 daytime hours, or some calculated combination of nighttime and daytime hours. 
[OlOtJ AHernatively a IhreshoW may be cateulated using a boolean contJina^ 

venda could potentially provkJe a rental application with no threshokl Every month, the software vendor obtains tfie* 
current vatoe of the SUSL and gets the audit trail. The vendor then validates the aucfit tral and charges a Ite aox)^ 
ingly. If the customer does not wish to contmue renting the software, then the vendor asks to have 9ie smart cardr 
returned. It is very easy toquery the vatoe of the SUSL if the customer briefly retwns ttw smert card to me vendor. Oth-^ 
envise. the vendor accessee the smart card via a network interface. Rrst the vendor generates a random nonce and 
asks tht customer to use WHie(nonce) to append the nonce to the auctit traa. Next, the vendor executes tfie 
VatidateTrail routine remotely. This service requires the customer (or programs that operate on the cu^omer's behaiO 
to relay the vendor's rec^jests from the network to the smart card. The vendor then checks the validated audit.trail for 
the nonce. 

Software Copy PMectton 

[01051 The software rental mechanism may be augmented with an addittonal software copy protection mechaiism. 
The software copy protection mechanism ensures that only ttie autfwized customer may rertt the program. The soft- 
ware copy protoctton mechanism may potentially share a keyfito with the software re^ 

rroiecieo woment 

[0106] Any of the rental mechanisms desatoed in this document rnay also be used for re 
to software. The approach is to rente Viewer program which uses a file. 
(0107J The foBowingpublicationsarecfted in this document 

[1] Hardtock API, Manual Implementation of Hartock Software Protection Systems. High-L^el API Version 3 Appfi- 
cation Programmmg Interface. FAST Software Security-Groupi FAST Document High-Level API. Revision: 4.00e, 
StatusMarchI, 1996 
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[2] A. Menezes et al. Handbook of Applied Cryptography. CRC Press. Inc. ISBN 0-8493-8523-7. S. 22 - 23. 224 - 
233, 250 • 259. 308 • 31 1 . 405 - 424, 433 • 438, 572 - 577. 1997 

[3] R. Rivest. The MD5 message-digest algorithm. RFC 1321. April 1992. 

(4) R Fenstermacher et al. Cryptographic randomness from air turbulence in disk drives. Advances in Cryptology: 
Crypto '94. pp. 114 - 120. Springer Verlag, 1994 

(5) D. Knuth. The Art of Computer Programming. Vol. 2. Seminumerical Algorithms, Addison-Wesiey Publishing 
Co.. Reading MA. 2nd Edition. 1981. pp. 38-73. ISBN 0-201-03822-6. 

Clainns 

1 . A software rental system comprising at least one rented program permitting at least one service to a customer with 
a customer's response means, wherein 

- said rented program has no access to a customer's private keying material, 

• using asymmetric cryptography, said customer s response means proves to the rented program, that said cus- 
tomer's response means has access to the customer s private keying material, and 

- said rented program does not permit sakJ at least one service to said customer unless the proof is successful, 

2. A software rental system comprising at least one rented program and private keying material such that the software 
rental system securely stores audit trails, wherein the correctness of said audit trails is validated using asymmetric^ 
cryptography. 

3. A software rental system according to claim 2 wherein the at least one rented program has no access to the private 
keying material. 

4. A software rental system according to claim 2 or 3 wherein the audit trails are conprising the extent to which the 
rented program has been rented. 

5. A software rental system according to claim 1 wherein vaMatk>n ensures alt of the following: 

no audit trail has been modified, 
35 - no audit trail has been deleted, and 

• the list of all audit trails is up to date. 

6. A software rental system in accordance to one of the claims 2 to 5 in whch the rented program fails to execute or 
executes in a limited mode if sad validation fails. 

40 

7. A software rental system in accordance to claim 0.5 in which the system may rent more programs than available 
Secure Updatable Storage Locations. 

8. A software rental system in accordance with claim 7 in which only a single Secure Updateable Storage Location is 
45 required In order to rent multiple programs. 

9. A software rental system in accordance with daim 8 in which a first part of the audH trail is stored on a non-secured 
media and a second part of the audit trail is stored in a secure updateable storage k)cation, wherein the first part 
of the audit trail comprises an amount of stored audit trails. 

50 

10. A software rental method using a software rental system in accordance with daim 9 in whkrfi a customer obtains 
and uses a secure updateable storage k>cation for rentwig software and subsequently obtains new rented software 
without requiring a new secure updateable storage k)cation or resetting an existing secure updateable storage 
location value. 

55 

11 . A software rental method in accordance with claim 1 0 in which multiple rented programs are using the same rental 
mechanism despite the fact that the rented programs were created without knowing common private keying mate- 
rial. 
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12. A software rental system according to daim 1 with multiple rented programs. 

13. A software rental system according to claim 12. wvh&^ein 

- said rented programs have the same keying material, and 
customer's priv^ keying material of said keying npiate^ 

14. A software rental system according to one of the claims 1 to 11. wherein a customer's private keying material is 
stored on a snwt card. 

15. A software rental system according to one of the claims 1 to 14. wherein 

at least one usage parameter of said at le^ one program ie stored in an audit trail, and 

- said rented program does net penrot said at least one service to saw a«^^ 
parameter is within a predetermined threshofel 

16. A software rerrtal system accoreling to daim 15. 

wherein at least two usage parameters of sakJ at least one program are stored in said audit trail. 

17. A software rental system accordtfig to daim 15 or 16. 

wherein said at least one usage parameter « a rental time period for renti^ 

16. A software rental system according to one of the daims 15 to 17. 

wherein stfd at least one usage parameter is an amourt of usages of said St ie«8t on^ 

19. A software rental system according 10 one of the dakns 15 to 18, wherein ^ 

- said at least one usage parameter is checked twi^ tknes, and 

- said remed program does not permit said m least one service to saw customs 
parameter is in a predetermined interval each time it is checked. 

20. A software rental system according to one of the daims 1 to 19. 

with a rental senrer that synchronizes aocess to a smart cad on whk:h a customer's private keymg material is ^ 
stored and/or to an auM trail in which usage parameters of sakl at least one program s stored. 

21. A software rental system axordir^ to one of the daims 15 to 20. wherein 
said program staes said at least one usage parameter in said audit trail. 

22. A software rentalsystemacooRfingtodatm 21. wherein 
sakJ audit trail is stored securely 

23. A80ltoerererMsyMroaccoidin§toOMoltheQlmie13to22.^^ 
the anart card pertomw an atomic routine that bott^ 

a staagetocatkyi that changee over time. 

24. A software rent^ system according to one of the daims 1 to 23. wherevi 
the progrwn is a viewer program which uses a fflSL 

25. A software rental system according to one of the daims 1 to 24. 
wherein the system indudes a keyfie tor holding public keying rnaterial. 

26. A software rental system according to daim 25, 

wherein said public keying material hekJ in said keyf ile is cryptographically secured, whereby it is conputatk)ruyry 
infeasiWe to alter any portton of the keyfie. indudirtg said pubfic keying material, without altering the dmdenge 
means. 

Z7, A software rental system according to claim 26. 

wherein sakJ keyf iie indudes information klentifying said customer sakl program has been sufsplied. 
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28. A software rental system according to claim 27, 

wherein said keyf ile includes decoy bits for disguising the said public keying material held therein, 

A software rental system according to one of the claims 1 to 28. wherein the program is copy protected. 

A method of distributing a program to a plurality of customers wherein each customer has a software rental system 
according to claim 1 or 2. and wherein every customer receives an identical copy of said program. 

A method for renting software comprising at least one rented program permitting at least one service to a customer 
with a customer's reponse means, wherein 

- said rented program has no access to a customer's private keying material. 

- using asymmetric cryptography, said customer's reponse means proves to the rented program, that said cus- 
tomer's reponse means has access to the customer's private keying material, and 

- said rented program does not permit sakl at least one service to said customer unless the proof is successful. 

A method for renting software comprising at least one rented program and private keying material such that the 
software rental system securely stores audit trails, wherein the correctness of saki audit trails is validated using 
asymmetric ayptography. 

33. A method according to claim 32 wherein sakl at least one rented program has no access to the private keying mate- 
rial. 

34. A method according to daim 32 or 33 wherein the audit trails are comprising the extent to whwh the rented program 
25 has been rented. 

35. A method according to daim 32 wherein validatton ensures all of the foltowing: 

• no audit trail has been modified. 

30 ' no audit trail has been deleted, and 

• the list of all audit trails is up to date. 

36. A method in accordance to one of the daims 31 to 35 in whk:h the rented program fails to execute or executes in a 
limited mode if said validation fails. 

35 

37. A method in accordance one of the claims 31 to 36 in which the system may rent more programs than available 
Secure Updatable Storage Locattons. 

38. A method in accordance with daifti 37 in which only a single Secure UpdateaWe Storage Locatton is required in 
40 order to rent multiple programs. 

39. A method in accordance with daim 38 in which a first part of the audit trail is stored on a non-secured media and 
a second part of the audit trail is stored in a secure updateaWe storage locatwn, wherein the first part of the aufit 
trail comprises an amount of stored audit trails. 

45 . 

40. A software rental method using a software rental system in accordance with claim 39 in whk:h a customer obtains 
and uses a secure updateable storage location for renting software and subsequently obtains new rented software 
without requiring a new secure updateable storage location or resetting an existing secure updateabie storage 
location value. 

50 

41. A method according to one of the claims 31 to 40 with multiple rented programs. 

42. A method according to daim 41 . wherein 

55 sakl rented programs have the same keying material, and 

. customer's private keying material of saki keying material is stored on a smart card. 

43. A method according to daim 42, wherein a customer's private keying material is stored on a smart card. 
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44. A method according to one of the claims 31 to 43. wherein 

at least one usage parameter of said at least one program is stored in an audit trail, and 
said rented program does not permit said at least one service to said customer unless said at least one usage 
5 parameter is withtn a predetermined threshold. 

45. A method according to daim 44. 

wherein at least two usage parameters of said at least one program are stored in said audit trail. 

to 46. A method according to daim 44 or 45. 

wherein said at least orte usage parameter is a rental time period for renting said at least one program. 

47. A method acoorcfing to one of the daims 31 to 46. 

wherein said at least one usage parameter is an amount of usages of said at least one program 

15 

48. A method according to one of the claims 31 to 47. wheron 

said at least one usage parameter is checked mult^ile times, and 
- said rented pro-am does not permit said at least one service to said customer unless said at least one usage 
20 parameter is in a predeternruned intend each tnne it is checked. 

49. A method acoordtfig to one of the dainrs 31 to 48. 

wi#i a rental server that syndvonizes access to a smart card on which a customer's private keying material is 
stored and/or to an au(£t trail in which usage parameters of said at l^st one program is stored. 

25 

50. A method according to one of the daims 31 to 49. wherein said program stores said at least one usage parameter 
in said aufit trail. 

51 . A method according to daim 50. wherein said audit trail is stored securely. 

30 

52. A method according to one of tie daims 31 to 5 1 . wherein the smart card performs an atomic routine that both exe- 
cutes a digital signature and an operatk)n computed over a storage locatk)n tfiat changes over time. 

53. A method according to one of the daims 31 to 52. wherein the program is a viewer program which uses a fila 

35 

54. A mettiod according to one of the clamis 31 to 53. 

wfierein the system indudes a keyf ile for holding pkMc keying material. 

55. A method according to daim 54. 

40 wherein said put)lic keytrtg material hekl in said keyffle is ayptographicaily secured, wtiereby it is computationally 
infeasft>le to alter any portton of the keyfile. including the public keying material, without attering the challenge 
meansw 

56. A method according to daim 55. 

45 wherein said keyfile indudes information identifying said customer said program has been supplied. 

57. A method according to daim 56. 

wherein said keyfile indudes decoy bits for disguising the said public keying material heki therein. 

50 58. A method according to one of the claims 31 to 57. wherein the program is copy protected. 
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